Yeah, tests will come if we like this behavior.

In case it gets lost: #2164 (comment)

isnt there a library for env files? imho flask shouldnt reimplement

@RonnyPfannschmidt i'm not going to pull in a one liner dependency here.

@untitaker the behavior here is consistent with other libraries that implement .env loading.

So maybe we put the conversation back to where this started: the goal was to make it easier during development to refer to the current Flask app. I do not see this as a feature for production. However let's see if we can figure out the production case as well.

How does one refer to their own app in production without exporting env variables?

@mitsuhiko I agree, good idea to pull back a bit.

I think referring to the app instance should work in the same way for development and production, I don't see why the methods should differ, since the app instance is the same in all cases. And there is also the complication of app factories, which are not friendly to FLASK_APP (#2027).

What I do, is define a wsgi.py file for each of my projects. I started adopting this as a convention, so I can have a hardcoded FLASK_APP=wsgi.app set in my .profile file and switch from app to app without worries. Would you consider implementing one or more sensible defaults for FLASK_APP? I think wsgi.application and wsgi.app are fairly common and could be defaults.

I've also commonly seen .env files used to store secrets, and managed via Ansible Vault or similar.

How does one refer to their own app in production without exporting env variables?

I do it by not using the flask command directly. Instead, I install an entry point to the project's own FlaskGroup, configured appropriately, and expect the project to be installed in the env both in development and production.

cli = FlaskGroup(create_app=create_app)

setup(
    ...,
    entry_points={
        'console_scripts': [
            'myapp=myapp.cli:cli.main',
        ],
    },
    ...,
)

FLASK_DEBUG=1 myapp run

One option for making this play nicer with the factory pattern is to allow making a call in the FLASK_APP var. Gunicorn and uWSGI allow this. gunicorn myapp.app:create_app(where='dev')

@mitsuhiko

How does one refer to their own app in production without exporting env variables?

Is this a valid question? Because you could also say "how does one refer to their own app in production without creating an instance/settings.py file", and then it becomes the same thing.

At the end of the day, this file needs to be on the production box for the app to be usable.

Personally, I use Docker and it has mechanisms for supplying an .env file of my choosing, then it makes those env variables available to the Flask app with no extra dirty work.

Without Docker, I would likely drop an environment file in /etc/default/fooapp which is the defaco-standard place on a Debian system to write out app-level environment variables. Then I would source that file in whatever init system I use.

In other words, in both development and production this env file would be available to the Flask app.

If this feature does end up being implemented, please let us configure the .env filename.

I would much prefer to use env variables instead of config/instance files because it plays much nicer when trying to scale applications on infrastructures that let you define clusters of servers, but then can define env variables in a central area (outside of each individual host), and then they become available to all hosts without worrying about the logistics of getting an env file on the system.

This could be done now of course, but it kind of goes against the norm which is to use config/instance based config files instead of env variables.

If I'm understanding this correctly, this would only read the .env when executed from the CLI, correct? That seems like it setting developers up for mistakes, I can see the bug reports and SO questions now: "Flask loads my .env file when I run the development server, but not when executed from uWSGI"

If this was going to be added, I'd rather see it implemented into either the Flask class or config class to at least be consistent between server options.

I did it by adding this into virtual environment's activate script, the variable will be set automatically when the virtual environment was activated. No multiple application crashing, no new file.

For example:
Unix Bash: venv/bin/activate:

FLASK_APP=foo.py
export FLASK_APP

Windows CMD.exe: venv\Scripts\activate.bat:

set "FLASK_APP=foo.py" 
:END

I don't recommend editing activate scripts.

@untitaker More detail?

I already elaborated in the PR you sent. You are editing random files which will get overwritten if you recreate the virtualenv (e.g. because it grew too big, or because a Python upgrade trashed it).

How about adding an entry point in setup.py to tell the flask command where the app is, similar to how we can add extra commands? Since we're encouraging the use of setup.py anyway, might as well take advantage. Not sure how we would handle multiple packages with the entry point though, if that ever comes up.

See #2234 (comment)

I'm leaning on the side of rejecting this. I agree that it would cause confusion, and we already have a documented way to set the env when working locally.